Hi Gerald,

I don't think there are any performance advantages regarding in vb.net vs your current methods using KMviaVB.dll to send Corrdinate Motion Segments. But there are examples of sending console commands such as:

_Controller.WriteLine(

String.Format("Accel{0}={1}", 0, 500))

There have been two recent changes to the CoordMotionC++ Library and KFLOP that improve throughput:

#1 - A Linear Coordinated Motion consists of a lot of parameters that consist of a starting point (up to 8 axes), and ending point (up to 8 axes), and parametric equation coefficients (5 values). See:

http://www.dynomotion.com/Help/Cmd.htm#LinearHex

http://www.dynomotion.com/Help/Cmd.htm#LinearHexEx

In most cases the starting point is the same as the previous ending point so it can be eliminated. Also if a linear segment is used for several phases of motion (acceleration, constant velocity, deceleration) then for the 2nd or 3rd phases of the motion only the parametric equation changes and there is no need to re-specify the endpoint. New KFLOP Script commands have been added that support the elimination of unnecessary parameters. See LHEX1 and LHEX2 commands defined in DSP_KFLOP\PC2.c (sorry they haven't been added to the Help files yet). Unfortunately these are only currently available for 6 axes commands. You are one of the few doing your own trajectory planning with 8 axes motion. We can add equivalent 8 axes commands if you feel this is important and can change your code to do the necessary logic. You might look at how the CCoordMotion handles the logic and uses the new commands in:

int CCoordMotion::OutputSegment(int iseg)

#2 - There is some Windows/USB overhead with each WriteLine command to KFLOP (User App pipes data to KMotionServer, ServerApp wakes up send to Windows Kernel Driver, Driver sends to USB, status is piped back to App, etc...). Which might be on the order of several hundred microseconds per WriteLine. KFLOP now accepts multiple Console Commands within one WriteLine operation if the commands are separated by semicolons. Packing console commands can reduce overhead. The maximum string that can be sent to KFLOP at one time is defined as:

#define MAX_LINE 2560

Regards

Group: DynoMotion	Message: 4362	From: Brad Murry	Date: 3/27/2012
Subject: Re: Quick Start needed in dotnet for VB

There are a few performance advantages that .net offers over vb6, depending on what you are doing.

Hello Gerald,

If you have a lot of string manipulation(like converting a file of points to numbers, etc…) there will be advantages as vb6 creates a new string every time you modify it.

See here::

http://msdn.microsoft.com/en-us/library/aa260972(v=vs.60).aspx

File reading, memory streaming and a few other things are optimized as well.

So the argument can only be made with stipulations based on you use case.

-Brad

From: DynoMotion@yahoogroups.com [mailto:DynoMotion@yahoogroups.com] On Behalf Of Tom Kerekes
Sent: Tuesday, March 27, 2012 9:14 AM
To: DynoMotion@yahoogroups.com
Subject: Re: [DynoMotion] Quick Start needed in dotnet for VB

Hi Gerald,

_Controller.WriteLine(

String.Format("Accel{0}={1}", 0, 500))

There have been two recent changes to the CoordMotionC++ Library and KFLOP that improve throughput:

http://www.dynomotion.com/Help/Cmd.htm#LinearHex

http://www.dynomotion.com/Help/Cmd.htm#LinearHexEx

int CCoordMotion::OutputSegment(int iseg)

#define MAX_LINE 2560

Regards

From: geraldft <geraldoft@...>
To: DynoMotion@yahoogroups.com
Sent: Tuesday, March 27, 2012 4:23 AM
Subject: [DynoMotion] Quick Start needed in dotnet for VB

Hi Tom / Brad

Looking for info to get quick started in vb.net. I want to find out if it can offer any performance advantages - especially in efficiency when uploading big lists of Linear functions.

I am having trouble finding information to help explain how to use dot.net. The .chm file you have mentioned before does not appear to have any descriptions or explanations - it's just a list of functions.

In the RH panel I get :

Navigation to the webpage was cancelled...?

But mainly - To get started though I would like to know how to send console commands with dot.net using vb. The demo Dynomotion VB.net application does not cover this.

Also - there seems to be no Kflop connection routine in the Dynomotion VB.net example. How is this handled?

If I try to run the program with no kflop attached it just returns an invalid operation exception error and refuses to start. It would be useful if the example showed how to handle this situation.

Finally - one more question. Are the latest incarnations of dynomotion dot.net hardware version dependant? This is quite important since I'd rather not have to change firmware on too many cards!

Also is there any chance of going to USB3 in the future?

Thanks Gerald

Group: DynoMotion	Message: 4393	From: geraldft	Date: 3/27/2012
Subject: Re: Quick Start needed in dotnet for VB

Thanks for the quick replies!

First of all though I am not using VB6 - I am using Visual Studio 2008 with Visual Basic. Generally I have found the string manipulation quite fast enough. In some cases I use the stringbuilder class which is much faster for making very long strings. But generally - aside from some weird cross platform issues (XP vs Win7) that end is not a problem. In my procedures to upload the data, if I comment the linear writeline to Kflop out of the equation, then the speed changes dramatically - so the string manipulation time is quite insignificant.

It was just when I come to upload thousands of lines of linear move data it can become an issue. I already have a preloading routine that prepares the first 10 seconds of the move. Once it starts then more data is uploaded progressively keeping it 'fed'. At higher rates of playback this can be happening constantly which creates some problems for GUI response. I have synchronised processes and achieve up to 8x realtime rate at present. This equates to 400 lines per second. Now I can feed the Kflop faster than this (I once managed to achieve 1,000 lines per second max.) but not at the same time as fulfilling all the other GUI requirements - and not equally in XP vs Win7 so faster upload would help.

Re Tom's reply - being able to combine more than one Linear command in one line would make a big difference. But do I need to upgrade the firmware? - all my clients are on v4.25. To change all these will be a big headache!

Because of the way my motion paths are created it is not possible to make use of data saving techniques like not re-specifying the end point. But if I can just send the next destination then this would allow twice as many lines to be sent simultaneously.

At present the only parameters I change are the start and end position of each of 8 axes, plus the second to last value, which is the number of data lines per second, and finally the time between each data point. Note the last two values never change during a sequence. If an axis is accelerating or changing direction this information is conveyed by the position change alone.

Only if I want to change the overall rate of playback then these last two values are changed.

In your answer you mentioned LinearHex - I use Linear (dec) - does this have the same ability to optimise data?

Also - to clarify - are these new options only available with Kmotion dot.net? Or are they only with a particular version of firmware?

"The maximum string that can be sent to KFLOP at one time is defined as: #define MAX_LINE 2560 "

Is there a default value for this? Also is this a console command or only for c scripts?

"You might look at how the CCoordMotion handles the logic and uses the new commands in: int CCoordMotion::OutputSegment(int iseg) "

Where am I looking for this? Btw I don't read c++ very well...

Meanwhile - Many thanks for the info...

Gerald

--- In DynoMotion@yahoogroups.com, Brad Murry <bradodarb@...> wrote:
>
> There are a few performance advantages that .net offers over vb6, depending on what you are doing.

> If you have a lot of string manipulation(like converting a file of points to numbers, etcâ¦) there will be advantages as vb6 creates a new string every time you modify it.
>
> File reading, memory streaming and a few other things are optimized as well.
>
> -Brad
>

> From: DynoMotion@yahoogroups.com [mailto:DynoMotion@yahoogroups.com] On Behalf Of Tom Kerekes
> Sent: Tuesday, March 27, 2012 9:14 AM
> To: DynoMotion@yahoogroups.com
> Subject: Re: [DynoMotion] Quick Start needed in dotnet for VB

>
> I don't think there are any performance advantages regarding in vb.net vs your current methods using KMviaVB.dll to send Corrdinate Motion Segments. But there are examples of sending console commands such as:
>
> _Controller.WriteLine(
>
> String.Format("Accel{0}={1}", 0, 500))
>
> There have been two recent changes to the CoordMotionC++ Library and KFLOP that improve throughput:
>
> #1 - A Linear Coordinated Motion consists of a lot of parameters that consist of a starting point (up to 8 axes), and ending point (up to 8 axes), and parametric equation coefficients (5 values). See:
>
> http://www.dynomotion.com/Help/Cmd.htm#LinearHex
>
> http://www.dynomotion.com/Help/Cmd.htm#LinearHexEx
>
> In most cases the starting point is the same as the previous ending point so it can be eliminated. Also if a linear segment is used for several phases of motion (acceleration, constant velocity, deceleration) then for the 2nd or 3rd phases of the motion only the parametric equation changes and there is no need to re-specify the endpoint. New KFLOP Script commands have been added that support the elimination of unnecessary parameters. See LHEX1 and LHEX2 commands defined in DSP_KFLOP\PC2.c (sorry they haven't been added to the Help files yet). Unfortunately these are only currently available for 6 axes commands. You are one of the few doing your own trajectory planning with 8 axes motion. We can add equivalent 8 axes commands if you feel this is important and can change your code to do the necessary logic. You might look at how the CCoordMotion handles the logic and uses the new commands in:
>
> int CCoordMotion::OutputSegment(int iseg)
>
> #2 - There is some Windows/USB overhead with each WriteLine command to KFLOP (User App pipes data to KMotionServer, ServerApp wakes up send to Windows Kernel Driver, Driver sends to USB, status is piped back to App, etc...). Which might be on the order of several hundred microseconds per WriteLine. KFLOP now accepts multiple Console Commands within one WriteLine operation if the commands are separated by semicolons. Packing console commands can reduce overhead. The maximum string that can be sent to KFLOP at one time is defined as:
>
> #define MAX_LINE 2560
>
> Regards
>
> TK
>
>
> From: geraldft <geraldoft@...>
> To: DynoMotion@yahoogroups.com
> Sent: Tuesday, March 27, 2012 4:23 AM
> Subject: [DynoMotion] Quick Start needed in dotnet for VB
>
> Hi Tom / Brad
>
> Looking for info to get quick started in vb.net <http://vb.net/> . I want to find out if it can offer any performance advantages - especially in efficiency when uploading big lists of Linear functions.
>
> I am having trouble finding information to help explain how to use dot.net <http://dot.net/> . The .chm file you have mentioned before does not appear to have any descriptions or explanations - it's just a list of functions.
>
> In the RH panel I get :
>
> Navigation to the webpage was cancelled...?
>
> But mainly - To get started though I would like to know how to send console commands with dot.net using vb. The demo Dynomotion VB.net application does not cover this.
>
> Also - there seems to be no Kflop connection routine in the Dynomotion VB.net example. How is this handled?
>
> If I try to run the program with no kflop attached it just returns an invalid operation exception error and refuses to start. It would be useful if the example showed how to handle this situation.
>
> Finally - one more question. Are the latest incarnations of dynomotion dot.net hardware version dependant? This is quite important since I'd rather not have to change firmware on too many cards!
>
> Also is there any chance of going to USB3 in the future?
>
> Thanks Gerald
>

Group: DynoMotion	Message: 4396	From: Tom Kerekes	Date: 3/27/2012
Subject: Re: Quick Start needed in dotnet for VB

Hi Gerald,

I agree with you the PC string manipulation is negligible and not a factor to be considered.

Combining semicolon separated Console commands into one WriteLine is a new feature of KFLOP and requires a firmware update V4.29z or higher.

It sounds like you could reduce data by almost half using new commands that would allow only endpoints. We would need to change the firmware to add 8 axis commands. All these are raw KFLOP console commands and do not depend on any .NET or even KMotionDLL capability other than a WriteLine call which already exists.

I didn't realize you were using Linear (decimal). Converting a binary representation of a floating point number to decimal ASCII characters is very computationally intensive probably requiring 50 double precision floating point operations including divisions, remainders, exponents, and so forth. This has to be performed one way on the PC and in reverse in KFLOP. This is very inefficient compared to converting a 32 bit memory location to hexadecimal. It also can cause round off problems if not enough decimals are specified, where hexadecimal transmission is basically doing a 32 bit memory move and so is exact. Also realize that each Linear Segment has 21 values that need to be converted. It is also a bit more compact. The only benefit to decimal is that it is more human readable. So I strongly urge you to switch to use Hexadecimal. All that being said I'm not exactly sure how much actual difference it would make :}

I don't fully understand your question on the Max Line Length. You can't change it. Of course you can send shorter lines. For any particular version it is fixed. You can find what the max is by what is defined in KMotionDLL.h It has always been 2560 characters.

Search the *.cpp files for "CCoordMotion::OutputSegment" and you will find it.

Regards

Group: DynoMotion	Message: 4398	From: Brad Murry	Date: 3/27/2012
Subject: Re: Quick Start needed in dotnet for VB

Hello Gerald,

You would need to be manipulating large strings to see any benefit(like your entire points path from a file).

I would say if you have a functional app that is stable and don’t plan on adding too many features then stick with the vb6 et al.

**Caution, partial bias ahead**

If you plan to add new features, integrate other devices or platform technologies or wish to improve your GUI’s responsiveness that you spoke about, then the .net path will likely be easier, more convenient and more robust.

I say more robust only because the threading models are of no comparison and there are more features available on the .net side.

But again, it sounds like you have a solid system going and no change is required at this time.

-Brad Murry

From: DynoMotion@yahoogroups.com [mailto:DynoMotion@yahoogroups.com] On Behalf Of geraldft
Sent: Tuesday, March 27, 2012 7:15 PM
To: DynoMotion@yahoogroups.com
Subject: [DynoMotion] Re: Quick Start needed in dotnet for VB

--- In DynoMotion@yahoogroups.com, Brad Murry <bradodarb@...> wrote:
>
> There are a few performance advantages that .net offers over vb6, depending on what you are doing.

> If you have a lot of string manipulation(like converting a file of points to numbers, etcâ€¦) there will be advantages as vb6 creates a new string every time you modify it.
>
> File reading, memory streaming and a few other things are optimized as well.
>
> -Brad
>

> From: DynoMotion@yahoogroups.com [mailto:DynoMotion@yahoogroups.com] On Behalf Of Tom Kerekes
> Sent: Tuesday, March 27, 2012 9:14 AM
> To: DynoMotion@yahoogroups.com
> Subject: Re: [DynoMotion] Quick Start needed in dotnet for VB

>
> I don't think there are any performance advantages regarding in vb.net vs your current methods using KMviaVB.dll to send Corrdinate Motion Segments. But there are examples of sending console commands such as:
>
> _Controller.WriteLine(
>
> String.Format("Accel{0}={1}", 0, 500))
>
> There have been two recent changes to the CoordMotionC++ Library and KFLOP that improve throughput:
>
> #1 - A Linear Coordinated Motion consists of a lot of parameters that consist of a starting point (up to 8 axes), and ending point (up to 8 axes), and parametric equation coefficients (5 values). See:
>
> http://www.dynomotion.com/Help/Cmd.htm#LinearHex
>
> http://www.dynomotion.com/Help/Cmd.htm#LinearHexEx
>
> In most cases the starting point is the same as the previous ending point so it can be eliminated. Also if a linear segment is used for several phases of motion (acceleration, constant velocity, deceleration) then for the 2nd or 3rd phases of the motion only the parametric equation changes and there is no need to re-specify the endpoint. New KFLOP Script commands have been added that support the elimination of unnecessary parameters. See LHEX1 and LHEX2 commands defined in DSP_KFLOP\PC2.c (sorry they haven't been added to the Help files yet). Unfortunately these are only currently available for 6 axes commands. You are one of the few doing your own trajectory planning with 8 axes motion. We can add equivalent 8 axes commands if you feel this is important and can change your code to do the necessary logic. You might look at how the CCoordMotion handles the logic and uses the new commands in:
>
> int CCoordMotion::OutputSegment(int iseg)
>
> #2 - There is some Windows/USB overhead with each WriteLine command to KFLOP (User App pipes data to KMotionServer, ServerApp wakes up send to Windows Kernel Driver, Driver sends to USB, status is piped back to App, etc...). Which might be on the order of several hundred microseconds per WriteLine. KFLOP now accepts multiple Console Commands within one WriteLine operation if the commands are separated by semicolons. Packing console commands can reduce overhead. The maximum string that can be sent to KFLOP at one time is defined as:
>
> #define MAX_LINE 2560
>
> Regards
>
> TK
>
>
> From: geraldft <geraldoft@...>
> To: DynoMotion@yahoogroups.com
> Sent: Tuesday, March 27, 2012 4:23 AM
> Subject: [DynoMotion] Quick Start needed in dotnet for VB
>
> Hi Tom / Brad
>
> Looking for info to get quick started in vb.net <http://vb.net/> . I want to find out if it can offer any performance advantages - especially in efficiency when uploading big lists of Linear functions.
>
> I am having trouble finding information to help explain how to use dot.net <http://dot.net/> . The .chm file you have mentioned before does not appear to have any descriptions or explanations - it's just a list of functions.
>
> In the RH panel I get :
>
> Navigation to the webpage was cancelled...?
>
> But mainly - To get started though I would like to know how to send console commands with dot.net using vb. The demo Dynomotion VB.net application does not cover this.
>
> Also - there seems to be no Kflop connection routine in the Dynomotion VB.net example. How is this handled?
>
> If I try to run the program with no kflop attached it just returns an invalid operation exception error and refuses to start. It would be useful if the example showed how to handle this situation.
>
> Finally - one more question. Are the latest incarnations of dynomotion dot.net hardware version dependant? This is quite important since I'd rather not have to change firmware on too many cards!
>
> Also is there any chance of going to USB3 in the future?
>
> Thanks Gerald
>

Group: DynoMotion	Message: 4401	From: geraldft	Date: 3/27/2012
Subject: Re: Quick Start needed in dotnet for VB

Thanks for clarification on line length.

I already did a comparative test re hex vs dec and found no obvious advantage at the time of uploading. My program first generates floating point values for the data which are then converted to a string array. When uploading there is no conversion.

Instead I could pre-convert them to hex strings. But in the end it seems like swings and roundabouts unless the hex values are shorter than the dec strings - and then maybe I can send more per line? Kflop seems to deal with either format the same... or am I also reducing the total number of lines I can upload due to memory limit in Kflop?

In any case - I would need to update firmware... :(

--- In DynoMotion@yahoogroups.com, Tom Kerekes <tk@...> wrote:
>
> Hi Gerald,
> Â
> I agree with you the PC string manipulation is negligible and not a factor to be considered.
> Â
> Combining semicolon separated Console commands into one WriteLine is a new feature of KFLOP and requires a firmware update V4.29z or higher.Â
> Â
> It sounds like you could reduce data by almost half using new commands that wouldÂ allow only endpoints.Â We would need to change the firmware toÂ add 8 axis commands.Â All these are raw KFLOP console commands and do not depend on any .NET or even KMotionDLL capability other than a WriteLine call which already exists.
> Â
> I didn't realize you were using Linear (decimal).Â Converting a binary representation of a floating point number to decimal ASCII characters is very computationally intensive probably requiring 50 double precision floating point operations including divisions, remainders, exponents,Â and so forth.Â Â This has to be performed one way on the PC and in reverse in KFLOP.Â This is very inefficient compared to converting a 32 bit memory location to hexadecimal.Â It also can causeÂ round off problems if not enough decimalsÂ are specified, where hexadecimal transmission isÂ basicallyÂ doing a 32 bit memory move and soÂ is exact.Â Also realize that each Linear Segment has 21 values that need to be converted.Â It is also a bit more compact.Â The only benefit to decimal is that it isÂ more human readable.Â So I strongly urge you to switch toÂ use Hexadecimal.All that being said I'm not exactly sure how much actual difference it would make :}
> Â
> I don't fully understand your question on the Max Line Length.Â Â You can't change it.Â Of course you can send shorter lines.Â For any particular version it is fixed.Â You can find what the max is by what is defined in KMotionDLL.h It has always been 2560 characters.
> Â
> Search the *.cpp files for "CCoordMotion::OutputSegment" and you will find it.
> Â
> Regards
> TKÂ
> Â
> Â
>
> From: geraldft <geraldoft@...>
> To: DynoMotion@yahoogroups.com
> Sent: Tuesday, March 27, 2012 7:14 PM
> Subject: [DynoMotion] Re: Quick Start needed in dotnet for VB
>
>
> Â
> Thanks for the quick replies!
>
> First of all though I am not using VB6 - I am using Visual Studio 2008 with Visual Basic. Generally I have found the string manipulation quite fast enough. In some cases I use the stringbuilder class which is much faster for making very long strings. But generally - aside from some weird cross platform issues (XP vs Win7) that end is not a problem. In my procedures to upload the data, if I comment the linear writeline to Kflop out of the equation, then the speed changes dramatically - so the string manipulation time is quite insignificant.
>
> It was just when I come to upload thousands of lines of linear move data it can become an issue. I already have a preloading routine that prepares the first 10 seconds of the move. Once it starts then more data is uploaded progressively keeping it 'fed'. At higher rates of playback this can be happening constantly which creates some problems for GUI response. I have synchronised processes and achieve up to 8x realtime rate at present. This equates to 400 lines per second. Now I can feed the Kflop faster than this (I once managed to achieve 1,000 lines per second max.) but not at the same time as fulfilling all the other GUI requirements - and not equally in XP vs Win7 so faster upload would help.
>
> Re Tom's reply - being able to combine more than one Linear command in one line would make a big difference. But do I need to upgrade the firmware? - all my clients are on v4.25. To change all these will be a big headache!
>
> Because of the way my motion paths are created it is not possible to make use of data saving techniques like not re-specifying the end point. But if I can just send the next destination then this would allow twice as many lines to be sent simultaneously.
>
> At present the only parameters I change are the start and end position of each of 8 axes, plus the second to last value, which is the number of data lines per second, and finally the time between each data point. Note the last two values never change during a sequence. If an axis is accelerating or changing direction this information is conveyed by the position change alone.
>
> Only if I want to change the overall rate of playback then these last two values are changed.
>
> In your answer you mentioned LinearHex - I use Linear (dec) - does this have the same ability to optimise data?
>
> Also - to clarify - are these new options only available with Kmotion dot.net? Or are they only with a particular version of firmware?
>
> "The maximum string that can be sent to KFLOP at one time is defined as: #define MAX_LINE 2560 "
>
> Is there a default value for this? Also is this a console command or only for c scripts?
>
> "You might look at how the CCoordMotion handles the logic and uses the new commands in: int CCoordMotion::OutputSegment(int iseg) "
>
> Where am I looking for this? Btw I don't read c++ very well...
>
> Meanwhile - Many thanks for the info...
>
> Gerald
>
> --- In DynoMotion@yahoogroups.com, Brad Murry <bradodarb@> wrote:
> >
> > There are a few performance advantages that .net offers over vb6, depending on what you are doing.
>
> > If you have a lot of string manipulation(like converting a file of points to numbers, etcÃ¢â¬Â¦) there will be advantages as vb6 creates a new string every time you modify it.
> >
> > File reading, memory streaming and a few other things are optimized as well.
> >
> > -Brad
> >
>
> > From: DynoMotion@yahoogroups.com [mailto:DynoMotion@yahoogroups.com] On Behalf Of Tom Kerekes
> > Sent: Tuesday, March 27, 2012 9:14 AM
> > To: DynoMotion@yahoogroups.com
> > Subject: Re: [DynoMotion] Quick Start needed in dotnet for VB
>
> >
> > I don't think there are any performance advantages regarding in vb.net vs your current methods using KMviaVB.dll to send Corrdinate Motion Segments. But there are examples of sending console commands such as:
> >
> > _Controller.WriteLine(
> >
> > String.Format("Accel{0}={1}", 0, 500))
> >
> > There have been two recent changes to the CoordMotionC++ Library and KFLOP that improve throughput:
> >
> > #1 - A Linear Coordinated Motion consists of a lot of parameters that consist of a starting point (up to 8 axes), and ending point (up to 8 axes), and parametric equation coefficients (5 values). See:
> >
> > http://www.dynomotion.com/Help/Cmd.htm#LinearHex
> >
> > http://www.dynomotion.com/Help/Cmd.htm#LinearHexEx
> >
> > In most cases the starting point is the same as the previous ending point so it can be eliminated. Also if a linear segment is used for several phases of motion (acceleration, constant velocity, deceleration) then for the 2nd or 3rd phases of the motion only the parametric equation changes and there is no need to re-specify the endpoint. New KFLOP Script commands have been added that support the elimination of unnecessary parameters. See LHEX1 and LHEX2 commands defined in DSP_KFLOP\PC2.c (sorry they haven't been added to the Help files yet). Unfortunately these are only currently available for 6 axes commands. You are one of the few doing your own trajectory planning with 8 axes motion. We can add equivalent 8 axes commands if you feel this is important and can change your code to do the necessary logic. You might look at how the CCoordMotion handles the logic and uses the new commands in:
> >
> > int CCoordMotion::OutputSegment(int iseg)
> >
> > #2 - There is some Windows/USB overhead with each WriteLine command to KFLOP (User App pipes data to KMotionServer, ServerApp wakes up send to Windows Kernel Driver, Driver sends to USB, status is piped back to App, etc...). Which might be on the order of several hundred microseconds per WriteLine. KFLOP now accepts multiple Console Commands within one WriteLine operation if the commands are separated by semicolons. Packing console commands can reduce overhead. The maximum string that can be sent to KFLOP at one time is defined as:
> >
> > #define MAX_LINE 2560
> >
> > Regards
> >
> > TK
> >
> >
> > From: geraldft <geraldoft@>
> > To: DynoMotion@yahoogroups.com
> > Sent: Tuesday, March 27, 2012 4:23 AM
> > Subject: [DynoMotion] Quick Start needed in dotnet for VB
> >
> > Hi Tom / Brad
> >
> > Looking for info to get quick started in vb.net <http://vb.net/> . I want to find out if it can offer any performance advantages - especially in efficiency when uploading big lists of Linear functions.
> >
> > I am having trouble finding information to help explain how to use dot.net <http://dot.net/> . The .chm file you have mentioned before does not appear to have any descriptions or explanations - it's just a list of functions.
> >
> > In the RH panel I get :
> >
> > Navigation to the webpage was cancelled...?
> >
> > But mainly - To get started though I would like to know how to send console commands with dot.net using vb. The demo Dynomotion VB.net application does not cover this.
> >
> > Also - there seems to be no Kflop connection routine in the Dynomotion VB.net example. How is this handled?
> >
> > If I try to run the program with no kflop attached it just returns an invalid operation exception error and refuses to start. It would be useful if the example showed how to handle this situation.
> >
> > Finally - one more question. Are the latest incarnations of dynomotion dot.net hardware version dependant? This is quite important since I'd rather not have to change firmware on too many cards!
> >
> > Also is there any chance of going to USB3 in the future?
> >
> > Thanks Gerald
> >
>

Group: DynoMotion	Message: 4402	From: geraldft	Date: 3/27/2012
Subject: Re: Quick Start needed in dotnet for VB

Hi Brad

Thanks for the comments. Yes it's quite robust - but I am always adding new features...

VB 2008 does have advanced threading options - I tried using a background worker for example - to handle the uploading routine.
It worked brilliantly in XP but for some bizarre reason actually went much slower when I ran the application in Windows 7. So then I had to revert to normal threading and used some careful synchronisation of the timer with the GUI routines to share time better.

BTW - I still didn't get any response to the question about handling the Kflop connection in dynomotion dot.net. In the main form I am used to seeing a timer that tests and confirms the connection, otherwise it informs the program that there is no card, so no calls should be made to it - the demo doesn't seem to have this. Hence when I run without a Kflop connected it crashes. Is this handled somewhere other than the main form? - if the card is there then it all works fine...

Thanks Gerald

--- In DynoMotion@yahoogroups.com, Brad Murry <bradodarb@...> wrote:
>
> Hello Gerald,

>
> You would need to be manipulating large strings to see any benefit(like your entire points path from a file).

>
> I would say if you have a functional app that is stable and donât plan on adding too many features then stick with the vb6 et al.

>
> **Caution, partial bias ahead**
>
> If you plan to add new features, integrate other devices or platform technologies or wish to improve your GUIâs responsiveness that you spoke about, then the .net path will likely be easier, more convenient and more robust.

>
> I say more robust only because the threading models are of no comparison and there are more features available on the .net side.

>
> But again, it sounds like you have a solid system going and no change is required at this time.

>
> -Brad Murry

>
> From: DynoMotion@yahoogroups.com [mailto:DynoMotion@yahoogroups.com] On Behalf Of geraldft
> Sent: Tuesday, March 27, 2012 7:15 PM
> To: DynoMotion@yahoogroups.com
> Subject: [DynoMotion] Re: Quick Start needed in dotnet for VB
>
>
>
>
>
> Thanks for the quick replies!
>
> First of all though I am not using VB6 - I am using Visual Studio 2008 with Visual Basic. Generally I have found the string manipulation quite fast enough. In some cases I use the stringbuilder class which is much faster for making very long strings. But generally - aside from some weird cross platform issues (XP vs Win7) that end is not a problem. In my procedures to upload the data, if I comment the linear writeline to Kflop out of the equation, then the speed changes dramatically - so the string manipulation time is quite insignificant.
>
> It was just when I come to upload thousands of lines of linear move data it can become an issue. I already have a preloading routine that prepares the first 10 seconds of the move. Once it starts then more data is uploaded progressively keeping it 'fed'. At higher rates of playback this can be happening constantly which creates some problems for GUI response. I have synchronised processes and achieve up to 8x realtime rate at present. This equates to 400 lines per second. Now I can feed the Kflop faster than this (I once managed to achieve 1,000 lines per second max.) but not at the same time as fulfilling all the other GUI requirements - and not equally in XP vs Win7 so faster upload would help.
>
> Re Tom's reply - being able to combine more than one Linear command in one line would make a big difference. But do I need to upgrade the firmware? - all my clients are on v4.25. To change all these will be a big headache!
>
> Because of the way my motion paths are created it is not possible to make use of data saving techniques like not re-specifying the end point. But if I can just send the next destination then this would allow twice as many lines to be sent simultaneously.
>
> At present the only parameters I change are the start and end position of each of 8 axes, plus the second to last value, which is the number of data lines per second, and finally the time between each data point. Note the last two values never change during a sequence. If an axis is accelerating or changing direction this information is conveyed by the position change alone.
>
> Only if I want to change the overall rate of playback then these last two values are changed.
>
> In your answer you mentioned LinearHex - I use Linear (dec) - does this have the same ability to optimise data?
>
> Also - to clarify - are these new options only available with Kmotion dot.net? Or are they only with a particular version of firmware?
>
> "The maximum string that can be sent to KFLOP at one time is defined as: #define MAX_LINE 2560 "
>
> Is there a default value for this? Also is this a console command or only for c scripts?
>
> "You might look at how the CCoordMotion handles the logic and uses the new commands in: int CCoordMotion::OutputSegment(int iseg) "
>
> Where am I looking for this? Btw I don't read c++ very well...
>
> Meanwhile - Many thanks for the info...
>
> Gerald
>
> --- In DynoMotion@yahoogroups.com <mailto:DynoMotion%40yahoogroups.com> , Brad Murry <bradodarb@> wrote:
> >
> > There are a few performance advantages that .net offers over vb6, depending on what you are doing.
>
> > If you have a lot of string manipulation(like converting a file of points to numbers, etcÃ¢â¬Â¦) there will be advantages as vb6 creates a new string every time you modify it.
> >
> > File reading, memory streaming and a few other things are optimized as well.
> >
> > -Brad
> >
>
> > From: DynoMotion@yahoogroups.com <mailto:DynoMotion%40yahoogroups.com> [mailto:DynoMotion@yahoogroups.com <mailto:DynoMotion%40yahoogroups.com> ] On Behalf Of Tom Kerekes
> > Sent: Tuesday, March 27, 2012 9:14 AM
> > To: DynoMotion@yahoogroups.com <mailto:DynoMotion%40yahoogroups.com>
> > Subject: Re: [DynoMotion] Quick Start needed in dotnet for VB
>
> >
> > I don't think there are any performance advantages regarding in vb.net vs your current methods using KMviaVB.dll to send Corrdinate Motion Segments. But there are examples of sending console commands such as:
> >
> > _Controller.WriteLine(
> >
> > String.Format("Accel{0}={1}", 0, 500))
> >
> > There have been two recent changes to the CoordMotionC++ Library and KFLOP that improve throughput:
> >
> > #1 - A Linear Coordinated Motion consists of a lot of parameters that consist of a starting point (up to 8 axes), and ending point (up to 8 axes), and parametric equation coefficients (5 values). See:
> >
> > http://www.dynomotion.com/Help/Cmd.htm#LinearHex
> >
> > http://www.dynomotion.com/Help/Cmd.htm#LinearHexEx
> >
> > In most cases the starting point is the same as the previous ending point so it can be eliminated. Also if a linear segment is used for several phases of motion (acceleration, constant velocity, deceleration) then for the 2nd or 3rd phases of the motion only the parametric equation changes and there is no need to re-specify the endpoint. New KFLOP Script commands have been added that support the elimination of unnecessary parameters. See LHEX1 and LHEX2 commands defined in DSP_KFLOP\PC2.c (sorry they haven't been added to the Help files yet). Unfortunately these are only currently available for 6 axes commands. You are one of the few doing your own trajectory planning with 8 axes motion. We can add equivalent 8 axes commands if you feel this is important and can change your code to do the necessary logic. You might look at how the CCoordMotion handles the logic and uses the new commands in:
> >
> > int CCoordMotion::OutputSegment(int iseg)
> >
> > #2 - There is some Windows/USB overhead with each WriteLine command to KFLOP (User App pipes data to KMotionServer, ServerApp wakes up send to Windows Kernel Driver, Driver sends to USB, status is piped back to App, etc...). Which might be on the order of several hundred microseconds per WriteLine. KFLOP now accepts multiple Console Commands within one WriteLine operation if the commands are separated by semicolons. Packing console commands can reduce overhead. The maximum string that can be sent to KFLOP at one time is defined as:
> >
> > #define MAX_LINE 2560
> >
> > Regards
> >
> > TK
> >
> >
> > From: geraldft <geraldoft@>
> > To: DynoMotion@yahoogroups.com <mailto:DynoMotion%40yahoogroups.com>
> > Sent: Tuesday, March 27, 2012 4:23 AM
> > Subject: [DynoMotion] Quick Start needed in dotnet for VB
> >
> > Hi Tom / Brad
> >
> > Looking for info to get quick started in vb.net <http://vb.net/> . I want to find out if it can offer any performance advantages - especially in efficiency when uploading big lists of Linear functions.
> >
> > I am having trouble finding information to help explain how to use dot.net <http://dot.net/> . The .chm file you have mentioned before does not appear to have any descriptions or explanations - it's just a list of functions.
> >
> > In the RH panel I get :
> >
> > Navigation to the webpage was cancelled...?
> >
> > But mainly - To get started though I would like to know how to send console commands with dot.net using vb. The demo Dynomotion VB.net application does not cover this.
> >
> > Also - there seems to be no Kflop connection routine in the Dynomotion VB.net example. How is this handled?
> >
> > If I try to run the program with no kflop attached it just returns an invalid operation exception error and refuses to start. It would be useful if the example showed how to handle this situation.
> >
> > Finally - one more question. Are the latest incarnations of dynomotion dot.net hardware version dependant? This is quite important since I'd rather not have to change firmware on too many cards!
> >
> > Also is there any chance of going to USB3 in the future?
> >
> > Thanks Gerald
> >
>

Group: DynoMotion	Message: 4346	From: geraldft	Date: 3/27/2012
Subject: Quick Start needed in dotnet for VB

Group: DynoMotion	Message: 4350	From: Brad Murry	Date: 3/27/2012
Subject: Re: Quick Start needed in dotnet for VB

Group: DynoMotion	Message: 4356	From: Tom Kerekes	Date: 3/27/2012
Subject: Re: Quick Start needed in dotnet for VB